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Abstract 

This  report  defines  the  syntax  and  semantics  of  the  specification  language  MSR  2. 0,  and  gives  requirements 
for  a  run-time  environment  for  it.  Specifically,  it  defines  the  concrete  syntax  of  the  language  and  formalizes 
its  typing  and  execution  semantics  at  an  abstract  level.  It  also  describes  programming  environment  func¬ 
tionalities  such  as  type  reconstruction  and  facilities  for  controlling  execution.  MSR  2.0  is  a  specification 
language  based  on  first-order  multiset  rewriting  modulo  equations,  dependent  types,  and  subsorting.  This 
report  is  meant  to  act  as  its  “official”  definition,  as  various  subsets  have  appeared  in  previous  publications, 
for  example  0E!-  It  has  been  used  extensively  for  studying  cryptographic  protocols  Ennsuinnni  Hams] 
and  especially  Kerberos  5  m  nisi  snani].  It  was  also  used  experimentally  for  modeling  bio-molecular 
systems  m-  MSR  1.0 ,  the  precursor  of  this  version,  was  also  used  in  foundational  studies  for  crypto¬ 
protocols  mils]-  An  implementation  of  MSR  2.0  which  adheres  to  the  definition  presented  in  this  report 
has  been  written  in  Maude  Ham]. 
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Chapter  1 

Lexicon 


Throughout  this  report,  we  refer  to  MSR  2.0  as  MSR.  This  chapter  describes  the  lexicon  of  MSR  using 
regular  expressions.  Meta-synrbols  ( e.g ‘(’  and  “+’)  will  be  printed  as  normal  mathematical  text.  ASCII 
characters  or  their  traditional  rendering  (for  non-printable  characters)  will  be  written  using  a  typewriter 
font  or  in  hexadecimal  preceded  by  the  string  ‘Ox’. 


1.1  Spaces 

Spaces  (non-terminal  sp)  are  strings  of  one  or  more  white  space  (u,  ASCII  0x20),  tabulation  (\t,  ASCII 
0x09),  new  line  (\n,  OS-dependent  combination  of  \r  and  \f),  carriage  return  (\r,  ASCII  0x13),  and  form 
feed  (\f,  ASCII  0x12). 


sp  =  [u\t\n\r\f]  + 


1.2  Comments 

Comments  are  of  two  types: 

Single-line  comments  start  with  the  symbol  %  and  extend  to  the  end  of  the  line. 

System  directives  piggyback  on  this  syntax  and  have  the  form  ' idoken  args ,  where  token  is  a  reserved 
symbol  that  has  meaning  for  the  interpreter  only  and  args  are  the  arguments  it  may  take.  Directives 
instruct  the  run-time  system  to  interpret  certain  symbols  as  infix  with  a  certain  precedence,  for  example. 

Multi-line  comments  start  with  the  symbol  %{  and  extend  to  the  next  matching  occurrence  of  }°/0. 

Multi-line  comments  can  be  nested  and  therefore  should  be  ended  by  balanced  occurrence  of  }%. 
Unterminated  multi-line  comments  should  be  reported  as  errors  (in  particular  they  are  not  implicitly 
closed  when  encountering  the  end  of  the  current  file).  Unbalanced  occurrences  of  }7,  should  also  be 
reported  as  errors. 

A  comment  is  either  a  single-line  or  a  multi- line  comment. 

Comments  can  occur  at  any  point  in  a  file,  and  are  equivalent  to  the  empty  string.  For  example, 
‘myyofxxxU/oId’  is  equivalent  to  the  identifier  ‘myld’.  A  single-line  comment  (together  with  the  terminating 
\n)  can  similarly  be  excised. 
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singlelineComment  =  %.* 

multiline  Comment  =  °/0{[.\n]*}0/0 

comment  =  singlelineComment  +  multiline  Comment 


1.3  Special  Characters 

Special  characters  are  not  allowed  as  part  of  identifiers.  They  include  a  minimal  set  of  punctuation  and 
grouping  symbols. 


specialChar  =  [%. )  (}{] 


1.4  Reserved  Symbols 

A  number  of  otherwise  valid  identifiers  are  reserved  operators  of  MSR.  They  include  the  following,  each 
with  a  brief  description: 


include 

File  inclusion 

module 

Module  declaration 

import 

Imported  symbols  of  a  module 

export 

Exported  symbols  of  a  module 

* 

Import /Export  wild-card 

Label  separator 

type 

Type  classifier 

state 

Multiset  classifier 

-> 

Functional  type 

< : 

Subsort  declaration 

Irrelevant  variable 

= 

Equation  symbol 

for 

Anchored  role  header 

f orall 

Universal  quantifier 

exists 

Existential  quantifier 

=> 

Rewrite  rule  separator 

> 

State  element  separator 

empty 

Empty  multiset 

i 

Guard  separator 

if 

Guard  separator  (alternate  syntax) 

im 

Reserved  for  future  use 

1.5  Identifiers 

An  identifier  is  a  non-empty  string  of  printable  ASCII  characters  that  does  not  include  any  special  character, 
is  not  a  space,  a  comment,  or  a  reserved  symbol. 

id  =  [0x21  —  0x7e]  + 

Identifiers  are  separated  by  spaces  or  special  characters.  So,  ‘my  Id'  contains  two  identifiers  (‘my’  and 
‘Id’),  and  similarly  for  ‘my (Id)’. 


1.6  Errors 

An  error  message  should  be  output  whenever  one  of  the  following  situations  occur: 

1.  the  lexical  analyzer  encounters  an  occurrence  of  ),  }  or  }%  that  does  not  match  a  previous  occurrence 
of  (,  {,  or  •/,{,  respectively; 
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2.  the  lexical  analyzer  reaches  the  end  of  a  file  without  being  able  to  balance  all  occurrences  of  (,  or 
°/«{  with  corresponding  occurrences  of  ) ,  }  or  }°/0,  respectively. 

The  error  message  should  point  to  the  first  opening/closing  symbol  without  a  corresponding  closing/opening 
symbol. 
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Chapter  2 

Syntax 


This  chapter  describes  the  syntax  of  MSR  specifications  on  the  basis  of  the  lexical  entities  presented  in 
Chapter  [T]  We  use  standard  BNF  notation  for  this  purpose.  Meta-symbols  will  be  rendered  as  normal 
mathematical  text  ( e.g .,  or  The  meta-symbol  denotes  the  empty  string.  Terminals  are  displayed 
using  a  typewriter  font.  Non-terminals  are  written  using  a  slanted  font,  such  as  the  already  defined  id. 
Non-terminals  used  before  they  are  defined  will  be  written  in  gray  (e.g.,  subtp).  Occasionally,  portions  of 
syntax  can  be  reconstructed  from  the  context  or  by  default  rules,  or  are  otherwise  optional.  We  enclose  them 
in  square  braces  [. . .]  and  comment  on  it  in  the  text. 


2.1  Organizing  Specifications 

An  MSR  specification  can  be  split  among  a  number  of  files.  The  include  directive  is  provided  to  embed 
the  contents  of  a  hie  into  another  hie:  upon  encountering  ‘include  file’  the  compiler  replaces  this  statement 
with  the  contents  of  hie  file,  include  statements  can  be  nested,  but  should  not  be  circular. 

Although  it  is  natural  to  break  specihcations  in  hies  at  the  module  level,  we  adopt  the  more  liberal  policy 
of  allowing  include  directives  at  any  point  in  a  specification.  This  corresponds  to  having  parsing  proper 
begin  after  all  the  include  directives  have  been  expanded. 


2.2  Module  Infrastructure 

An  MSR  specihcation  is  organized  as  a  collection  of  modules,  possibly  interspersed  with  items  (declarations, 
equations,  roles,  or  state  objects  —  see  below)  and  commands.  Commands  are  mostly  used  at  the  top  level 
of  the  MSR  tool  and  their  use  in  a  module  is  not  encouraged. 

A  module  is  introduced  by  the  keyword  module,  labeled  by  a  unique  identiher,  and  defined  by  a  header 
and  a  body.  The  header  lists  symbols  imported  from  other  modules  and  exported  outside  the  dehning 
module.  The  body  of  a  module  declares  the  symbols  used  within  the  module  (with  the  exception  of  those 
imported),  the  equations  that  govern  them,  and  the  rules  that  operate  on  them. 

A  module  starts  with  the  keyword  module  and  ends  either  at  the  end  of  the  specification,  or  upon 
encountering  the  keyword  module  that  indicates  the  beginning  of  another  module.  Modules  cannot  be 
nested. 


MSRspec  :. 

=  •  |  module  MSRspec  \  item  MSRspec  \  command  MSRspec 

S 

module  ::= 

module  id  header  body 

M 

The  header  lists  symbols  imported  from  other  modules  and  exported  outside  the  defining  module.  Import 


4 


CHAPTER  2.  SYNTAX 


declarations  consist  of  the  keyword  import,  the  importing  module  name,  and  the  imported  items,  which  are 
either  a  single  body  item  or  a  comma-separated  list  of  labels.  They  end  with  a  period.  Exported  items 
consist  of  the  keyword  export,  a  comma-separated  list  of  labels,  and  a  period. 

header  ::=  imports  exports  H 

imports  ::=  •  |  imports  import  id*.  \  imports  import  id  id+  .  \  imports  import  id  item  I 

exports  ::=  •  |  export*.  |  exports  export  id+ .  X 

id+  ::=  id  \  id,  id+ 

Import  lists  will  generally  mention  only  labels  (id).  A  complete  item,  inclusive  of  the  label  and  the  type, 
equation  or  role  is  available  for  when  a  module  is  intended  for  separate  compilation.  When  labels  only  are 
given,  the  corresponding  items  shall  be  accessed  from  the  referenced  module.  Both  imports  from  a  same 
module  and  exports  can  be  grouped  or  broken  in  import  and  export  declarations  at  the  specifier’s  leisure. 
For  convenience,  the  wild-card  *  can  be  used  in  place  of  declarations  to  specify  that  a  module  shall  import 
all  symbols  exported  by  another  module,  or  that  it  exports  all  symbols  it  defines. 

The  scope  of  an  import  or  export  declaration  is  the  whole  module. 

The  body  of  a  module  is  a  sequence  of  body  items  (item),  which  consist  of  declarations  ( decl ),  equations 
(equation),  definitions  (definition),  and  roles  (role),  in  arbitrary  order.  As  will  become  apparent  in  the 
sequel,  items  consist  of  a  label,  a  colon  “ :  ” ,  and  typing  information,  an  equation  or  a  role.  The  label  and 
the  colon  are  optional  except  for  typing  information.  An  identifier,  i.e.,  a  label,  must  be  declared  before  its 
first  use  in  an  equation  or  a  role.  With  the  exception  of  roles,  body  items  end  with  a  period. 


item  ::=  decl 

|  equation . 

|  definition .  \  role 

b 

II 

© 

-o 

body  item 

B 

The  scope  of  an  item  extends  to  the  end  of  the  present  module.  It  is  expected  that  each  identifier  used 
in  a  module  be  declared  in  the  module,  and  that  no  two  declarations  declare  the  same  identifier. 

Commands  are  used  to  interact  with  and  guide  the  MSR  tool.  See  the  user  documentation  of  the  tool, 
currently  m ,  for  the  list  of  available  commands  and  their  effects. 


command  ::= 


2.3  Declarations 

A  declarations  is  either  a  type  declaration  (tpDecl),  a  subtype  declaration  (subtpDecl),  or  an  object  decla¬ 
ration  (objDecl).  Each  of  these  forms  will  be  terminated  by  a  period. 

decl  ::=  tpDecl  \  subtpDecl  \  objDecl  5 

It  is  expected  that  symbols  have  a  unique  declaration  in  a  module,  be  it  in  the  header  through  an  import 
statement,  or  in  the  body  as  a  proper  declaration. 

2.3.1  Type  Declarations 

Type  declarations  declare  type  constructors.  Because  MSR  is  dependently  typed,  we  define  types  before 
type  declarations  themselves. 
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A  base  type  is  either  the  reserved  symbol  state  or  an  identifier  possibly  applied  to  a  sequence  of  terms 
(its  arguments  or  indices).  A  type  is  either  a  base  type  or  a  dependent  function  type,  i.e.,  a  type  prefixed 
by  an  object  declaration. 


baseTp  ::=  state  | 

id  | 

baseTp  term 

a 

tp  ::=  baseTp  \  tp 

->  tp 

|  { objDeciytp 

T 

A  dependent  function  type  will  have  the  form  {x:r1}r2:  the  object  declaration  x:ti  binds  every  free  occur¬ 
rence  of  x  in  r2.  As  often  done,  we  abbreviate  this  expression  as  T\  ->  r2  whenever  x  does  not  occur  free  in 
t2 .  The  type  state  is  used  to  classify  multisets  and  their  elements^] 

Kinds  declare  type  constructors.  A  kind  is  either  the  symbol  type,  or  a  dependent  kind,  i.e.,  a  kind 
prefixed  by  an  object  declaration.  As  for  types,  we  use  the  abbreviation  r  ->  k  for  a  kind  {x :  t}«  where  x 
does  not  occur  in  n. 


kind  ::=  type  |  tp  ->  kind  \  {.objDeciykind  n 


The  kind  type  will  be  used  to  classify  types. 

A  type  declaration  is  a  pair  consisting  of  an  identifier  and  a  kind.  They  are  separated  using  a  colon,  and 
terminated  by  a  period  (see  item). 


tpDecl  ::=  id  :  kind 


Any  valid  identifier  can  be  declared  by  a  type  declaration,  with  the  exception  of  the  reserved  symbols  of 
MSR,  including  the  underscore 

Type  declarations  can  be  accompanied  by  directives  of  the  form  %name  r  X  that  instruct  the  compiler 
to  print  variables  of  type  r  it  may  produce  during  type  reconstruction  or  execution  using  the  symbol  X 
followed  by  progressive  numbers.  If  no  %name  directive  is  given,  the  default  is  to  use  X  followed  by  a 
progressive  number. 


tpDirective  ::=  “/name  id  id 


Other  directives  may  be  supported  by  the  implementation.  See  the  tool  documentation  m  for  further 
information. 

2.3.2  Subtype  Declarations 


A  subtype  is  a  pair  of  types  separated  by  < :  and  possibly  prefixed  by  a  number  of  object  declarations  enclosed 
in  braces.  A  subtype  declaration  is  a  subtype  terminated  by  a  period  (see  item). 


subtp  ::= 

tp  <:  tp 

|  {objDeciy subtp 

a 

subtpDecl 

::=  [id  : 

subtp 

In  most  cases,  the  object  declarations  prefixing  a  subtype  will  be  reconstructed,  either  in  part  or  in  full.  In 
the  former  case,  the  type  is  left  out  and  shall  be  inferred.  In  the  latter  case,  the  identifier  is  omitted  as  well. 
By  convention,  only  identifiers  beginning  with  a  capital  letter  or  underscore  (“_”)  can  be  assumed  to  have 
been  implicitly  declared  in  this  way. 

1  state  is  designated  as  a  type  mostly  to  simplify  the  structure  of  the  current  Maude  implementation  of  MSR  1181 1211.  It 
can  also  be  designated,  possibly  more  accurately,  as  a  kind.  While  the  choice  is  important  from  a  type- theoretic  perspective,  it 
has  little  effect  for  a  user  of  the  language  as  described  in  this  document.  Future  extensions  may  however  require  changing  this 
classification. 
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2.3.3  Object  Declarations 

Object  declarations  associate  an  identifier  with  a  type.  The  pair  is  separated  by  a  colon  and  terminated  by 
a  period  at  the  top  level  or  inside  modules  (see  item). 


objDecl  ::=  id  [:  tp\  o 


Any  valid  identifier  can  be  declared  by  a  type  declaration,  with  the  exception  of  the  reserved  symbols  of 
MSR,  including  the  underscore 

Within  a  rule,  the  type  part  of  an  object  declaration  can  often  be  reconstructed  by  the  context.  It  is 
omitted  in  those  cases.  The  typing  information  shall  be  present  in  module-level  declarations  or  at  the  top 
level. 

An  object  declarations  can  be  accompanied  by  a  directives  describing  non-standard  ways  to  parse  oc¬ 
currences  of  this  symbol.  A  unary  constant  /  can  be  declared  either  prefixed  or  postfixed  by  means  of  the 
directives  “/prefix  and  “/.postfix.  They  accept  a  precedence  as  a  second  argument.  Binary  symbols  can  be 
requested  to  be  infix  of  a  declared  precedence  and  associativity  (left,  right  or  none). 

Precedences  are  numbers  between  10,000  and  99,999.  Lower  and  higher  precedences  are  reserved  to 
describe  the  interpreted  operators  of  MSR.  Symbols  with  higher  precedences  bind  more  tightly  than  symbols 
with  lower  precedences.  As  a  default,  the  juxtaposition  of  symbols  is  to  be  considered  infix,  left-associative, 
and  with  precedence  5,000.  Precedences  can  be  overridden  using  parentheses. 

objDirective  ::=  "/.prefix  id  prec  |  “/.postfix  id  prec  |  "/.infix  id  prec  assoc 

prec  ::=  [1  —  9] [0  —  9]5 

assoc  ::=  left  |  right  |  none 

These  directives  are  available  for  the  convenience  of  the  user.  All  symbols  can  be  rewritten  in  standard  prefix 
form,  possibly  with  the  addition  of  extra  pairs  of  parentheses  where  necessary.  In  the  sequel,  we  will  assume 
that  this  expansion  phase  has  taken  place. 


2.4  Equations 

An  equation  relates  two  terms  with  the  symbol  =.  The  pair  can  optionally  be  prefixed  by  a  sequence  of 
declarations  for  the  variables  occurring  in  it,  although  this  information  can  generally  be  reconstructed. 
Another  optional  component  is  a  label  that  identifies  this  equation  for  export.  Equations  end  with  a  period 
(see  item). 

equation  ::=  [id  :]  eq 

eq  ::=  term  =  term  \  [forall  objDecl \  eq  E 

MSR  does  not  impose  a  format  on  the  left-hand  side  and  right-hand  side  of  an  equation.  However,  such 
formats  may  be  expected  from  the  term  rewriting  system  that  handles  equations  in  an  implementation. 
Therefore,  it  is  advisable  to  use  standard  formats  for  equations,  for  example  left  linear.  Formatting  error 
messages  will  be  relayed  by  the  underlying  term  rewriting  system. 


2.5  Definitions 

A  definition  introduces  an  abbreviation  for  a  term.  A  definition  can  be  parametric.  Formal  parameters 
are  specified  in  a  parameter  list  with  each  element  consisting  of  an  identifier  and  an  optional  type  (subject 
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to  reconstruction).  Parentheses  are  not  needed  if  the  type  is  omitted.  A  parameter  that  does  not  appear 
in  the  body  of  the  definition  (but  only  in  omitted  typing  information)  can  be  omitted  whenever  it  can  be 
reconstructed. 


A  definition  associates  an  identifier  followed  by  zero  or  more  formal  parameters  with  the  term  it  is  intended 
to  abbreviate.  Definitions  end  with  a  period  (see  item).  A  definition  cannot  be  recursive.  A  defined  constant 
is  used  exactly  like  a  declared  constant. 


2.6  Roles  and  Rules 

Roles  are  sequences  of  rules  bound  together  by  a  declaration.  Roles  may  declare  local  symbols  that  will  be 
called  existential  variables.  A  rule  consists  of  a  guard,  a  left-hand  side  and  a  right-hand  side.  These  three 
entities  are  defined  over  the  notion  of  multiset,  which  in  turn  relies  on  terms.  We  will  now  define  these 
objects  from  the  bottom  up. 


2.6.1  Terms 

A  term  is  either  an  identifier,  or  a  term  applied  to  another  term.  Juxtaposition  is  infix,  left-associative,  and 
with  precedence  5,000. 


The  last  production  annotates  a  term  with  a  certain  type.  It  is  included  for  debugging  purposes  upon  encoun¬ 
tering  a  type  reconstruction  error.  This  is  not  intended  as  a  substitute  for  providing  missing  declarations. 
It  is  always  possible  to  infer  the  type  of  a  term  given  sufficient  declarations. 


2.6.2  Multisets 

A  multiset  is  represented  in  MSR  as  a  comma-separated  list  of  terms.  For  convenience,  the  empty  multiset 
can  be  represented  either  as  the  empty  string  (in  which  case  no  surrounding  comma  is  required)  or  as  the 
terminal  empty. 


2.6.3  Rules 

A  rule  has  a  core  consisting  of  a  left-hand  side ,  a  right-hand  side  and  optionally  a  guard.  This  core  is  prefixed 
by  a  number  of  optional  object  declarations  introduced  by  the  keyword  forall.  The  left-hand  side  and  the 
guard  are  multisets.  The  right-hand  side  is  a  multiset  possibly  prefixed  by  a  sequence  of  object  declarations 
introduced  by  the  keyword  exists. 

rhs  mset  |  exists  objDecl  rhs  rhs 

rule  ::=  mset  =>  rhs  \  mset  ;  mset  =>  rhs  \  mset  =>  rhs  if  mset  |  [forall  objDecl]  rule  r 

The  base  syntax  for  a  rule  is  ug  ;  Ihs  =>  rhs ” .  An  alternative  way  to  write  the  same  expression  is 
“Ihs  =>  rhs  if  g" .  Whenever  the  guard  g  is  empty,  it  can  be  dropped,  simply  writing  “Uis  =>  rhs" . 
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The  scope  of  an  exist  declaration  extends  to  the  end  of  the  right-hand  side,  and  that  of  a  forall 
declaration,  either  explicit  or  implicit,  extends  to  the  end  of  the  current  rule. 

In  many  cases,  the  forall  declarations  in  a  rule  can  be  reconstructed,  either  in  full  or  in  part.  In  the 
former  case,  the  type  is  left  out  and  shall  be  inferred.  In  the  latter  case,  the  identifier  is  omitted  as  well.  By 
convention,  only  identifiers  beginning  with  a  capital  letter  or  underscore  ( )  can  be  assumed  to  have  been 
implicitly  declared  in  this  way. 

exists  declaration  can  be  reconstructed  only  in  part,  i.e.,  only  the  type  portion  of  these  declarations 
can  be  omitted. 

2.6.4  Roles 

A  rule  sequence,  rule*,  is  a  period-separated  list  of  rules,  possibly  interspersed  with  object  declarations 
introduced  by  the  exists  keyword.  These  will  serve  to  bind  identifiers  local  to  the  role.  An  optional  label 
may  prefix  a  rule. 

A  role  is  given  by  a  rule  sequence  enclosed  in  curly  braces,  and  prefixed  by  a  label  and  either  an  object 
declaration  or  by  the  form  “for  id" .  These  prefixes  are  intended  to  designate  the  owner  of  the  role. 

rule*  ::=  ■  |  empty  |  [id  :]  rule,  rule*  \  exists  objDecl  rule*  rs 

role  ::=  id  :  forall  objDecl  {  rule*  }  |  id  :  for  id  {  rule*  }  p 

The  scope  of  an  exists  declaration  extends  to  the  end  of  the  rule  set.  The  scope  of  the  forall  declaration 
of  a  role,  when  present,  extends  to  the  entire  rule  set  that  it  qualifies. 


2.7  Parsing 

The  parser  shall  recognize  valid  MSR  specifications  according  to  the  above  grammar  and  build  appropriate 
data  structures  to  support  subsequent  functionalities. 

Whenever  it  is  established  that  the  input  files  do  not  satisfy  this  grammar,  an  error  message  should  be 
output.  It  shall  be  accompanied  by  information,  as  precise  as  possible,  about  the  location  of  the  error. 
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Type  Reconstruction 


Each  constant  occurring  in  an  MSR  module  is  to  be  interpreted  as  having  been  introduced  by  a  declaration, 
either  in  the  header  of  the  current  module,  or  in  the  earlier  part  of  this  module,  or  in  a  dependent  prefix,  or 
in  an  equation  as  a  forall  declaration,  or  in  a  definition  as  a  formal  parameter,  or  in  a  role  (as  the  leading 
forall  or  through  exists),  or  inside  the  rule  itself  as  a  forall  or  exists  declaration.  The  latter  are  called 
the  local  variables  of  the  rule. 

As  a  matter  of  readability,  convenience  to  the  user  and  usability  of  the  tool,  a  number  of  declarations  and 
typing  information  can  be  omitted.  An  MSR  implementation  is  expected  to  either  reconstruct  this  omitted 
data,  when  this  can  be  done  unambiguously  according  to  the  rules  below,  or  issue  detailed  error  messages 
so  that  the  user  can  add  sufficient  text  to  help  the  compiler  reconstruct  omitted  parts. 

The  acceptable  omissions  fall  into  the  following  two  classes: 

•  Implicit  bindings  comprise 

—  the  forall  declarations  at  the  head  of  a  rule  or  equation, 

—  the  dependent  prefixes  of  a  type,  subtype,  or  kind,  and 

—  the  formal  parameters  of  a  definition  as  long  as  they  do  not  appear  in  the  body. 

•  Type  part  of  an  object  declaration. 

The  omitted  dependent  prefixes  of  a  type  or  kind  declaration  and  the  omitted  formal  parameters  of  a 
definition  also  lead  to  the  omission  of  the  corresponding  parameters  when  these  symbols  are  used. 

A  detailed  account  of  type  reconstruction  in  the  presence  of  dependent  types  can  be  found  in  M- 


3.1  Reconstruction  of  forall  Bindings 

The  binders  forall  X  :  r  occurring  in  a  rule  or  equation  can  be  omitted  as  long  as 

•  the  implicitly  bound  variable  starts  with  a  capital  letter  [A-Z]  or  the  underscore  or  is  the  under¬ 
score  symbol  by  itself,  which  has  a  special  interpretation  (see  below),  and 

•  type  r  can  be  reconstructed. 

Upon  encountering  an  undeclared  symbol  X  starting  with  a  capital  letter  or  the  underscore,  the  compiler 
shall  extend  the  rule  or  equation  it  occurs  in  with  the  prefix  forall  X  (the  still  implicit  type  is  reconstructed 
at  a  later  stage,  or  a  type  variable  a,  to  be  instantiated  subsequently,  can  be  inserted). 
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Each  occurrence  of  the  underscore  symbol  stands  for  a  different  implicitly  declared  variable.  Therefore, 
the  compiler  shall  replace  each  occurrence  with  a  different  new  variable  X,  and  extend  the  current  rule  with 
the  prefix  forall  X,  as  in  the  previous  case.  Because  of  this  special  interpretation,  the  underscore  symbol 
shall  not  be  declared. 

The  reconstruction  algorithms  outlined  in  this  section  apply  only  within  a  rule  or  an  equation,  and  not 
elsewhere.  It  shall  also  be  noted  that,  in  general,  this  simple  syntactic  binder  reconstruction  needs  to  be 
alternated  with  the  more  complex  reconstruction  of  omitted  types,  as  an  omitted  type  may  make  use  of  a 
yet  undeclared  variable. 


3.2  Reconstruction  of  Dependent  Prefixes 

Every  symbols  occurring  in  a  base  type  shall  be  declared  before  its  first  use.  However,  since  many  of  these 
declarations  are  bookkeeping  dependent  prefixes  of  the  type,  subtype,  or  kind  they  appear  in,  it  is  convenient 
to  omit  them  whenever  they  can  be  reconstructed. 

We  adopt  the  same  syntax  as  in  the  case  of  omitted  forall  declarations:  implicitly  declared  variables 
occurring  in  a  type  shall  begin  with  a  capital  letter  [A-Z]  or  the  underscore  ,  or  be  the  underscore.  The 
missing  binder  for  symbol  X  is  added  at  the  front  of  the  type,  subtype  or  kind  as  an  object  declaration  {A'} 
with  its  type  omitted  (or  temporarily  expressed  as  a  type  variable).  More  precisely,  we  extend 

•  a  type  r  into  {X}t, 

•  a  subtype  er  into  {X }er,  and 

•  a  kind  k  into  {X}k. 

Each  occurrence  of  the  underscore  is  first  replaced  with  a  different  identifier  before  this  extension  step. 

Whenever  a  symbol  starting  with  a  capital  letter  or  the  underscore  occurs  in  a  type  within  a  rule,  it  may 
need  to  be  expanded  as  either  a  forall  declaration  or  a  dependent  prefix.  In  general,  the  latter  is  preferred 
if  it  occurs  within  a  single  type  after  all  the  reconstruction  steps  have  been  performed.  A  forall  declaration 
is  necessary  only  when  this  symbol  occurs  in  two  or  more  different  types. 

Other  considerations  are  as  in  the  case  of  implicit  forall  declarations. 


3.3  Reconstruction  of  Omitted  Types 

Object  declarations  “x  :  r”  can  be  abbreviated  as  “x”  whenever  the  type  r  can  be  reconstructed  from 
the  context.  Type  reconstruction  information  is  obtained  from  previous  declarations.  For  example,  if  a 
specification  contains  an  explicit  or  reconstructed  declaration  /  :  r  — >  r'  for  a  symbol  /,  and  a  type 
{A}(. . .  fX  . . .)  where  the  type  of  X  has  been  omitted,  then  it  can  be  deduced  that  the  type  of  X  shall  be 

T. 

Type  reconstruction  is  usually  done  by  inserting  type  variables  in  place  of  the  omitted  types,  and  col¬ 
lecting  and  propagating  constraints  until  a  single  solution  emerges  (success),  the  constraints  are  found  to 
be  inconsistent  ( fatal  error),  or  all  possible  constraint  simplifications  have  been  attempted  but  constraints 
remain  ( underspecification  error).  In  the  latter  case,  the  author  of  the  specification  shall  be  invited  to  add 
typing  information  and  run  the  checker  again. 


3.4  Subtypes 

Whenever  a  type  subject  to  reconstruction  belongs  to  a  subtype  hierarchy,  the  result  shall  be  the  lower 
bound  of  all  types  occurring  in  the  constraints,  subject  to  the  usual  variance  and  contravariance  conditions. 
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For  example,  given  a  subtype  declaration  r  < :  t'  and  a  variable  whose  type  can  be  reconstructed  as  either 
r  or  t' ,  t  shall  be  preferred.  If  this  lower  bound  is  not  unique,  then  an  underspecification  error  shall  be 
returned. 


3.5  Definitions 

Every  symbol  occurring  in  the  body  of  a  definition  shall  either  appear  among  its  formal  parameters  or  be 
declared  earlier  in  the  module.  These  symbols  cannot  be  reconstructed  as  formal  parameters  since  their 
occurrence  order  would  be  up  to  the  implementation:  a  user  would  not  know  how  to  specify  actual  values 
when  using  the  definition.  However,  the  types  of  the  formal  parameters  are  subject  to  reconstruction. 
Moreover,  whenever  the  reconstructed  types  mention  variables  that  do  not  occur  in  the  body,  hence  new 
formal  parameters,  they  are  subject  to  full  reconstruction  since  the  implementation  can  decide  on  an  order 
both  at  the  definition  and  use  level,  without  user  input. 


3.6  Implicit  Arguments 

Whenever  an  identifier  declaration  relies  on  omitted  typing  information,  any  use  of  this  identifier  shall  omit 
all  arguments  corresponding  to  this  omitted  typing  information.  For  example,  if  /  is  declared  of  type  a  X  ->  b 
(by  means  of  the  declaration  f  :  a  X  ->  b)  where  the  type  of  X  is  kept  implicit,  then  every  use  of  /  shall 
take  the  form  /  t  for  some  term  t  of  type  a  t!  for  an  appropriate  term  t' .  If  instead  /  is  declared  of  type 
{X  :c}a  X  ->  b  (by  means  of  the  declaration  /  :  {A  :c}a  X  ->  b)  with  the  type  of  X  given  explicitly,  then 
every  use  of  /  can  only  be  of  the  form  f  t!  t  where  t'  has  type  c  and  t  has  type  a  t' . 

During  reconstruction,  these  omitted  arguments  shall  be  reconstructed  as  well. 


3.7  Output  of  Reconstructed  Information 

It  is  useful  to  have  the  implementation  return  successful  output  information  in  at  least  two  modes: 

Verbose.  In  this  mode,  the  compiler  shall  display  outputs  that  include  all  the  reconstructed  binding  and 
typing  information.  This  mode  is  useful  mostly  for  debugging  purposes. 

Normal.  Under  normal  usage,  the  compiler  shall  display  outputs  without  any  reconstructed  information. 
For  example,  if  the  specification  declares  a  function  fir'—}  t"  that  the  type  reconstruction  phase 
completes  as  /  :  {X  :  t}t'  — >  t",  uses  of  /  shall  have  the  form  / 1  (for  t  of  type  r'),  not  f  xt  for  an 
appropriate  x  of  type  r. 

Intermediate  modes  may  be  useful  if  it  is  found  that  the  verbose  mode  displays  overwhelming  amounts  of 

information,  but  the  normal  mode  is  too  succinct  to  permit  effective  debugging. 


3.8  Errors 

The  implementation  shall  report  an  error  whenever  omitted  parts  of  an  MSR  specification  cannot  be  recon¬ 
structed  unambiguously.  It  is  preferable  to  output  modules  and  other  declarations  as  soon  as  they  have  been 
fully  reconstructed  in  order  to  narrow  down  the  portion  of  a  program  that  requires  user  attention.  Error 
messages  should  be  as  informative  as  possible. 
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This  chapter  identifies  those  MSR  specifications  that  shall  be  viewed  as  sensible  by  requiring  symbols  to  be 
used  consistently  with  their  declaration.  This  is  achieved  by  laying  out  a  typing  semantics  on  top  of  the 
MSR  syntax  defined  in  Chapter  [2j  We  assume  that  implicit  information  has  been  reconstructed  in  full  as 
described  in  Chapter  [3j  Those  specifications  and  components  that  satisfy  the  typing  semantics  will  be  called 
valid. 

We  present  the  typing  semantics  of  MSR  using  judgments  defined  by  typing  rules,  following  the  format  of 
Structured  Operational  Semantics.  Whenever  a  meta-variable  of  any  postulated  syntactic  category  appears 
below,  it  shall  be  implicitly  assumed  that  it  stands  for  a  well-formed  expression  within  that  syntactic  category. 


4.1  Substitutions 

The  meta-level  operation  of  substitution  is  used  in  many  of  the  rules  needed  to  validate  judgments  involving 
dependent  types.  It  is  also  used  during  execution,  as  discussed  in  Chapter  [5] 

The  capture-avoiding  substitution  of  a  term  t  for  a  variable  x  in  an  object  o  of  the  appropriate  syntactic 
category  is  uniformly  denoted  [t/x]o  for  each  class  of  objects.  In  case  of  ambiguity,  the  specific  category  of 
o  will  be  indicated  using  a  superscript,  as  in  [t / x]mset rhs .  Substitution  is  defined  for  all  syntactic  categories 
except  modules  and  their  headers,  bodies,  definitions  and  roles. 


Terms 


Term  substitution,  [t/x]t'  propagates  across  the  structure  of  the  term  t'  until  an  identifier  is  found.  If  this 
identifier  is  the  variable  x ,  it  is  replaced  with  t ,  otherwise  it  remains  unchanged. 


[t/x\y 

Wx\(t't") 

WxW  :  T) 


1 1  if  y  =  x 
1  y  otherwise 

([tMt')  {[t/x]t") 
(([t/x]?)  :  ([t/x]r)) 


Kinds,  Types,  and  Subtypes 

Substitution  propagates  across  the  structure  of  kinds,  types  and  subtypes  until  a  term  is  encountered,  where 
substitution  on  terms  is  invoked.  The  substitution  meta-operation  is  capture-avoiding:  whenever  it  traverses 
a  binding  construct,  such  as  a  dependent  type,  it  implicitly  renames  the  bound  variable  to  a  symbol  different 
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from  x  if  needed. 


Kinds:  [t/x]  type 

[t/x\({y  :  t}k) 

Types:  [i/x]state 

[t/x]y 
[t/x](a  t') 

[' t/x]({y  :  t}t') 

Subtypes:  [ t/xMr  <:  t') 

[t/x\{{y  :  r}cr) 


type 

{V  '■  [t/x]T}{[t/x\n) 

state 

([ t/x\a)  {[t/x]*) 

{y  ■  [t/x\T}([t/x\T’) 

(Wx\r)  <:  {[t/x\T') 
{y  ■■  [t/x\r}([t/x\a) 


Equations 

Substitution  over  equations  traverses  the  universal  quantifiers,  renaming  their  bound  variables  as  needed, 
and  then  invokes  term  substitution  on  each  side  of  the  equality  symbol. 

[f/x](forall  y  :  t.E )  =  forally  :  ([t / x\t) .([t / x\E) 

[t/x](t'  =  t")  =  ([  t/x]t')  =  {[t/x]t") 


Multiset,  Rules,  and  Rule  Sequences 


Substitution  over  multisets  reduces  to  the  term  substitution  over  each  member  term.  Substitution  over 
right-hand  sides  traverses  the  existential  quantifiers,  renaming  their  bound  variables  as  needed,  and  then 
invokes  multiset  substitution.  Substitution  over  rules  traverses  the  universal  quantifiers,  renaming  their 
bound  variables  as  needed,  and  then  invokes  multiset  substitution  on  the  guard  and  left-hand  side,  and 
right-hand  side  substitution  on  the  right-hand  side  of  each  rule.  Substitution  over  a  rule  sequence  reduces  to 
rule  substitution  over  each  embedded  rule.  The  existential  quantifiers  are  traversed,  renaming  their  bound 
variables  as  needed. 


Multisets: 
Right-hand  sides: 
Rules: 


Rule  sequences: 


[t/x]  empty 
[t/x](m,t') 

[t/x]m 

[t/x] (exists  y  :  r.rhs) 

[t/x](m;m'  =>  rhs ) 
[£/x](f  orall  y  :  r.r) 

[t/x]  empty 
\t/x]{r.rs) 

[t/x] (exists  y  :  r.rs ) 


empty 

([t/x]m),  ( [t/x] t' ) 

[t/x\msetm 

exists  y  :  ([t / x\t) .([t / x\rhs) 

([t/x]m);  ([t/xjm7)  =>  ([t/x]rhs) 
f orall  y  :  ([t/x]r).([t/x]r) 

empty 

([t/x]r).([t/x]rs) 

exists  y  :  ([t/x]r).([t/x]rs) 


4.2  Typing  Judgments 

The  typing  semantics  of  MSR  is  specified  on  the  basis  of  the  following  judgments,  which  follow  closely  the 
syntax  described  in  Chapter  [2j  The  definition  of  these  judgments  is  given  in  the  next  section. 
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b  S  spec 

S  b  M  module 
Shi  imports 
B  b  X  exports 

b  P  context 
r  b  B  body 

r  b  k  kind 
T  \-  t  :  k 
T  b  <7  inst 

rhfieq 

r  b  t  :  t 
r  h  to  mset 
r  b  rhs  rhs 
T  b  r  rule 
r  b  rs  rules 
r  h  p  role 


S  is  a  valid  specification 

M  is  a  valid  module  in  specification  S 
I  is  a  valid  import  list  ui.r.t.  specification  S 
X  is  a  valid  export  list  w.r.t.  extended  body  B 

r  is  a  valid  context 
B  is  a  valid  body  in  context  P 

n  is  a  valid  kind  in  context  T 
t  is  a  valid  type  of  kind  k  in  context  P 
a  is  a  valid  subtype  in  context  T 

E  is  a  valid  equation  in  context  T 

t  is  a  valid  term  of  type  r  in  context  P 

to  is  a  valid  multiset  in  context  T 

rhs  is  a  valid  right-hand  side  in  context  T 

r  is  a  valid  rule  in  context  T 

rs  is  a  valid  ride  sequence  in  context  T 

p  is  a  valid  role  in  context  T 


4.3  Typing  Rules 

4.3.1  Specifications 

A  valid  MSR  specification  (b  S  spec)  is  a  possibly  empty  sequence  of  modules.  Each  module  shall  be  valid 
in  the  context  provided  by  the  subspecification  that  precedes  it.  This  is  in  order  to  verify  the  validity  of 
import  statements. 

b  S  spec  S  is  a  valid  specification 

b  S  spec  S  b  M  module 

- vS_-  - vS_M 

b  •  spec  b  S  M  spec 


This  judgment  depends  on  the  judgment  validating  a  module  w.r.t.  a  specification  ( S  b  M  module), 
described  below. 


4.3.2  Modules 


A  module  M  consisting  of  an  identifier  id,  an  import  list  I,  an  export  list  X  and  a  body  B  is  valid  w.r.t.  a 
specification  S  when  the  import  list  is  valid  w.r.t.  S,  the  body  prefixed  with  the  inlining  of  /  is  valid,  and 
this  same  entity  includes  the  export  list  X. 


S  b  M  module 


M  is  a  valid  module  in  specification  S 


S  b  /  imports 


•  b  inlines (/),  B  body  inline s( -I ), -B  b  X  exports 

S  b  module  id  I  X  B  module 


vM 


This  judgment  depends  on  the  judgment  validating  an  import  list  w.r.t.  a  specification  (Shi  imports),  the 
judgment  validating  the  body  of  a  module,  extended  with  all  the  items  it  recursively  imports  (T  b  B  body), 
the  function  inlines  (-0  that  retrieves  the  items  corresponding  to  an  import  list  from  the  modules  where  they 
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were  originally  introduced,  the  auxiliary  functions  /  and  X,  and  the  judgment  that  validates  an  export  list 
w.r.t.  the  extended  body  {B  h  X  exports). 

The  rest  of  this  section  defines  these  judgments,  with  the  exception  of  the  validation  of  the  extended 
body,  which  is  specified  in  the  next  section.  For  convenience,  we  first  define  the  auxiliary  functions  I  and 
X,  that  break  an  import  and  an  export  list  so  that  each  import  or  export  statement  contains  one  label  (or 
the  wild-card  *,  or  an  actual  body  item  cum  label  c  :  b). 


JI,  import  id  * 

I,  import  id  b 
I,  import  id  (cs,  c) 
I,  import  id  c 


I, import  id  * 

I,  import  id  b 

I,  import  id  cs,  import  id  c 
I, import  id  c 


X,  export  * 

X ,  export  (cs,  c) 
X ,  export  c 


X , export  * 

X , export  cs,  export  c 
X, export  c 


The  function  inlines  (/)  recurses  over  the  list  I.  It  is  assumed  that  /  has  been  expanded  using  the  function 
I.  For  reasons  of  succinctness,  we  will  treat  the  cases  where  an  element  refers  to  a  label  c  and  a  body  item 
(c  :  b)  together,  writing  c[:  b],  which  shall  be  understood  as  the  former  if  b"  is  absent,  and  as  the  latter 
otherwise.  For  each  element  in  I ,  inlines  (I)  produces  the  corresponding  item  from  the  importing  module. 
This  item  can  be  found  in  either  its  body,  or  in  its  import  list,  in  which  case  inlines (-)  calls  itself  recursively. 
When  encountering  an  import  id  *  declaration,  it  imports  the  body  of  module  id  and  calls  itself  recursively 
on  its  import  list. 

inlines  (•)  =  • 

inlines  ((import  id  *),  I)  =  inlines'(//),  B,  inlines(/) 
where  S  =  S' ,  (module  id  I'  X  B),  S" 

<  inlines  ((import  id  c[:  b]),I)  =  c  :  b,  inline,s(/) 

where  S  =  S',  (module  id  /'  X  ( B ,  c  :  b,  B ')),  S " 

inlines  ((import  id  c[:  b]),I)  =  inlines'  (import  id'  c\:  6]),  inlines  (I) 
where  S  =  S',  (module  id  (/',  import  id'  c[:  b],I")  X  B),  S" 

A  valid  import  list  consists  of  either  generic  statements  import  id  *,  or  of  precise  items  import  id  c[:  b\. 
In  the  first  case,  it  is  sufficient  to  verify  that  module  id  exists  in  the  preceding  part  of  the  specification.  In 
the  second  case,  it  is  also  necessary  to  verify  that  this  module  exports  that  item. 

S  \~  I  imports  I  is  a  valid  import  list  w.r.t.  specification  S 

Shi  imports 

- vl  - vl_* 

S  h  •  imports  S',  (module  id  I'  X  B),S"  h  I,  (import  id  *)  imports 

- - V - ' 

s 

Shi  imports  (c  :  b)  €  (inlin es'(l'),B)  inlines'(/,)7 ^  c  exports 

- vl_l 

S',  (module  id  I'  X  B),  S"  h  I,  (import  id  c[:  6])  imports 

N.  > 

S 


This  judgment  relies  on  the  judgment  validating  an  export  list  w.r.t  to  an  extended  module  (B  h  X  exports), 
described  next. 

An  extended  body  is  always  allowed  to  export  *.  An  extended  body  exports  a  label  c  if  an  item  c  :  b  is 
contained  in  it. 
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B  b  X  exports 

X  is  a  valid  export  list  w.r.t.  extended  body  B 

- vX_ 

B  b  •  exports 


B  b  X  exports  B  b  X  exports 

- vXa  - vXI 

B  \-  X,  (export  *)  exports  B',  c  :  b ,  B"  b  X ,  (export  c)  exports 

B 


This  judgment  does  not  depend  on  any  other  judgment. 

4.3.3  Bodies  in  Context 

The  (inlined)  body  of  a  module  is  a  sequence  of  declarations,  equations,  definitions,  and  roles.  Each  of 
these  objects  can  refer  to  identifiers  declared  or  defined  earlier  in  the  body.  The  list  of  declared  identifiers  is 
maintained  in  a  context. 

Contexts 

A  context  T  is  an  ordered  list  of  kind  declarations,  type  declarations,  or  subsorting  declarations.  It  is  assumed 
that  any  declared  symbol  occurs  exactly  once  in  a  context.  A  context  is  given  by  the  following  grammar: 


r  ::=  •  |  T,  x  :  n  |  T,  x  :  t  |  P,  x  :  a 


Note  that  contexts  are  not  legal  MSR  entities,  but  they  form  a  helper  syntactic  category  for  the  purpose  of 
type  checking. 

A  context  is  valid  if  each  declaration  occurring  in  it  is  valid  with  respect  to  the  earlier  declarations  in 
the  context.  Therefore,  a  kind  declaration  x  :  k  is  valid  if  k  is  a  valid  kind  with  respect  to  the  earlier  part 
of  this  context.  Similarly  for  type  and  subsort  declarations. 

b  T  context 

b  T  context  T  b  n  kind 

- vr  - vr.K 

b  •  context  b  T,  x  :  k  context 

b  T  context  T  b  r  :  type  |-  p  context  T  b  a  subsort 

- vr.r  - vr_<r 

b  r, x  :  r  context  b  T,x  :  a  context 

This  judgment  depends  on  the  judgment  validating  a  kind  (T  b  k  kind),  the  judgment  validating  a  type 
(T  b  t  :  type),  and  the  judgment  validating  a  subsorting  relation  (T  b  a  subsort).  All  are  described  in  the 
next  section. 

Bodies 

A  body  is  valid  if  all  items  it  contains  are  valid  in  the  context  consisting  at  least  of  all  preceding  declarations. 
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T  b  B  body 

B  is  a  valid  body  in  context  F 

h  P  context  r  b  n  kind  Y,x  :  k  b  B  body 

- vB_  - vB.k 

r  b  •  body  r  b  x  :  n,B  body 


T  b  r  :  type  r,i:r  h  B  body  r  b  a  subsort  F,x  :  a  b  B  body 

- vB  _r  - vB_cr 

T  b  x  :  t,  B  body  T  b  x  :  a,  B  body 

T  h  o  body  T,o  b  t  :  t  T,:r  :  {o}r  b  B  body 

- - vB_D 

T  b  x  o  :=t.  B  body 


rhBeq  r  b  B  body 

- vB.E 

r  h  x  :  E.  B  body 


r  b  p  role  r  b  B  body 

- vB_p 

T  \-  x  :  p.  B  body 


This  judgment  depends  on  the  judgment  that  checks  the  validity  of  a  context  (b  T  context),  defined  above. 
It  also  depends  on  the  judgments  validating  a  kind  (I  h  s  kind),  a  type  (T  h  r:  type),  a  subsorting  relation 
(T  b  a  subsort),  a  term  (T  b  t,  :  r),  an  equation  (T  b  E  eq)  and  a  role  (T  b  p  role).  The  judgments  in 
this  last  class  will  be  defined  in  the  next  few  sections. 

Each  of  these  rules  adds  an  object  to  the  current  context.  As  they  do  so,  they  verify  the  validity  of 
this  object.  Therefore,  the  check  performed  by  rule  vB_-  can  be  omitted  whenever  this  judgment  is  initially 
called  with  an  empty  context. 

Rule  vB  D  validates  a  definition  x  o  :=  t  where  x  is  the  defined  identifier,  o  is  the  list  of  parameters 
of  the  definition,  and  t  is  the  defining  term.  The  first  premise  verifies  that  each  declaration  in  o  is  valid  in 
the  current  context.  With  a  slight  abuse  of  notation,  we  rely  on  an  independent  call  to  the  body  validation 
judgment  to  perform  this  check.  The  second  premise  verifies  that  t  is  a  valid  term  of  some  type  r  in  the 
current  context  extended  with  the  parameters,  the  third  premise  makes  x  available  for  the  validation  of  the 
rest  of  the  body  B.  Its  type  is  set  to  be  the  dependent  type  given  by  r  prefixed  with  each  of  the  declarations 
in  o,  in  order.  Formally,  {o}t  is  defined  as  follows: 

/  {'l7-  =  T 

\  {0  :  t')o}t  =  {x  :  r}({o}r) 

The  identifier  prefixing  a  subsorting  declaration  and  an  equation  is  optional.  When  not  present,  it  is 
assumed  that  the  type  checker  synthesizes  a  new  unique  identifier  and  associates  it  with  this  entity. 

4.3.4  Declarations 

Declarations  are  issued  for  kinds,  types  and  subsorts.  This  section  defines  the  judgments  that  decide  whether 
a  kind,  a  type  and  a  subsort  are  valid. 

Kinds 

Kinds  classify  types  and  type  constructors.  The  kind  type  is  valid  in  any  context.  A  dependent  kind  is  valid 
if  each  prefixing  object  declaration  has  a  valid  type  with  respect  to  the  current  context  augmented  with  the 
object  declarations  preceding  it. 
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r  h  t  :  type  T,:r  :  r  h  k  kind 

-  vK.type  - vkJI 

r  h  type  kind  P  h  {x:  t}k  kind 


This  judgment  relies  on  the  type  validation  judgment  (T  h  r  :  k)  defined  later  in  this  section. 

Subsorts 


A  subsorting  declaration  is  valid  if  both  sides  of  <:  are  valid  types  in  the  current  context  augmented  with 
declarations  for  each  prefixing  dependent  object. 


P  h  r  :  type  T  b  t'  :  type  T  h  r  :  type  P,a:  :  r  h  er  subsort 

- vcr_< :  - v<T_n 

T  h  t  <:t  subsort  T  V  {x  :  r}a  subsort 


This  judgment  depends  on  the  judgment  validating  types  (T  h  r  :  k)  defined  next. 

Subtypes 


Type  r  is  a  valid  subtype  of  t'  if  it  is  a  valid  subsort  of  t'  ,  if  both  are  obtained  by  instantiation  with  a  valid 
term  of  the  expected  type,  or  if  they  can  be  linked  transitively  by  these  two  rules. 


r  h  a  subsort  _  T  b  t,  :  r  T  h  {x  :  r}cr  inst 

- vi  (T-base  - vicr  n 

T,ct,  T'  h  a  inst  T  h  [t/x]a  inst 


T  h  r  <:  t'  inst  T  h  t'  <:  t"  inst 

- via_<: 

P  h  t  <:  t"  inst 

This  judgment  depends  on  the  just  introduced  judgment  validating  subsorts  (T  h  a  subsort)  and  on  the 
judgment  validating  terms  (r  h  t  :  r)  defined  in  a  section  to  come. 

Types 

Types  classify  terms.  Types  and  type  constructors  are  in  turn  classified  by  kinds.  This  judgment  decides 
whether  a  type  belongs  to  a  given  kind  with  respect  to  a  given  context.  A  constant  declared  in  the  context 
of  some  valid  kind  n  has  that  kind,  unless  it  is  the  constant  state  that  has  kind  type  unconditionally.  A 
base  type  (a  t)  is  validated  by  discovering  the  type  r  of  t  and  checking  that  a  has  a  kind  dependent  on  r. 
The  kind  of  ( a  t )  is  obtained  by  replacing  any  mention  x  with  t.  A  dependent  type  {a;  :  r}r '  shall  always 
have  kind  type,  and  the  same  applies  for  the  embedded  types  r  and  t' .  Because  of  the  dependency  on  x, 
the  type  t'  must  be  validated  in  a  context  extended  with  the  declaration  x  :  r. 
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T  b  r  :  k 

r  is  a  valid  type  of  kind  n  in  context  F 

P  b  k  kind 

- vr_6ase  - vt.state 

P,  a  :  n,  K  b  a  :  n  T  b  state  :  type 


r  h  i:r  T  b  a  :  {cc  :  t}k 

- VT_atm 

r  b  at  :  [t./x\n 


r  b  t  :  type  r,  x  :  r  b  t'  :  type 

- vr_n 

r  b  {x  :  r}r' : type 


This  judgment  relies  on  the  judgment  validating  a  kind  (T  b  k  kind)  defined  above,  on  the  judgment 
validating  a  term  (P  h  t  :  t)  defined  in  a  section  to  come,  and  on  the  substitution  operation  defined  earlier. 

4.3.5  Equations 

An  equation  is  valid  if  both  sides  have  the  same  type  in  the  current  context  augmented  with  declarations 
for  each  object  in  its  forall  prefix. 

T  b  E  eq  E  is  a  valid  equation  in  context  F 

P  h  :  t  T  h  f2  :  t  Pbr:  type  r,  x  :  t  b  E  eq 

- vE_=  - vE_V 

T  h  h=f2  eq  f  h  forall  x  :  t.E  eq 


This  judgment  depends  on  the  judgment  validating  terms  (r  b  t  :  r)  introduced  in  the  next  section  and  the 
judgment  validating  types  (T  b  r  :  k)  defined  earlier. 


4.3.6  Roles  and  Rules 


Terms 

A  term  is  valid  if  it  is  a  known  constant  applied  to  zero  or  more  valid  terms.  An  application  1 1'  is  typechecked 
by  discovering  the  type  t'  of  t'  and  checking  that  t  a  type  {x  :  t'}t  dependent  on  r' .  The  type  of  t  t'  is 
obtained  by  replacing  any  mention  of  x  in  r  with  t! .  Rule  vt  <:  specifies  that  a  term  can  also  be  validated 
by  looking  for  any  supertype.  By  rule  vt_  :,  a  term  can  only  be  annotated  with  a  valid  type. 


fhf: 


t  is  a  valid  term  of  type  r  in  context  T 


T  h  r:  type 
r,  c  :  r,  r'  b  c  :  r 

T  b  t  :  t 
T  b  (t  :  t)  :  t 


vt-base 


T  b  t'  :  t  T  b  t  :  {x  :  t'}t 
Tbft':  \t' /x\t 

T  b  t  <:  t'  inst  T  b  t  :t' 

T  b  t  :  t 


vt_n 


vt_<: 


This  judgment  depends  on  the  judgment  validating  types  (T  b  r  :  n)  and  on  the  judgment  validating 
subtypes  (T  b  a  inst),  both  introduced  earlier. 

Multisets 

Multisets  are  possibly  empty  connna-separated  lists  of  terms  of  type  state. 
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P  b  m  mset  T  \-  t  :  state 

- vm  .empty  - vm_, 

P  b  empty  mset  r  h  m,f  mset 


This  judgment  depends  on  the  typing  judgment  for  terms  (T  b  t  :  r)  defined  above. 

Rules 


A  valid  rule  right-hand  side  is  a  multiset  prefixed  by  zero  or  more  variable  declarations  exists  x  :  r,  each 
for  a  valid  type  r.  The  embedded  multiset  may  make  use  of  these  variable  declarations. 


T  h  to  mset  T  b  t  :  type  T,i:rh  rhs  rhs 

- vrhs  _base  - vrhs_3 

P  b  in  rhs  T  b  exists  x  :  r.  rhs  rhs 


This  judgment  relies  on  the  judgment  validating  types  (T  b  r  :  k),  defined  earlier. 

A  valid  rule  has  at  its  core  a  two  valid  multisets,  the  guard  and  the  left-hand  side,  and  a  right-hand 
side.  This  core  is  prefixed  by  zero  or  more  variable  declarations  f  orall  x  :  r,  each  for  a  valid  type  r.  The 
constituents  of  core  may  make  use  of  these  variable  declarations. 


T  b  r  :  type  T,x  :  t  b  r  rule  P  b  to  mset  T  b  m'  mset  T  b  rhs  rhs 

- vr_V  - vr_=> 

r  b  f orall  x  :  r.r  rule  T  b  m\m!  =>  rhs  rule 


This  judgment  depends  on  the  judgments  validating  types  (P  b  r  :  n),  multisets  (P  b  m  mset),  and 
right-hand  sides  (r  b  rhs  rhs),  all  introduced  earlier. 

Roles 


A  rule  sequence  is  valid  it  is  either  empty  or  a  list  of  valid  rules.  Rules  in  a  rule  sequence  may  be  interspersed 
with  existential  variable  declarations  exists  x  :  r  which  may  be  used  in  subsequent  rules.  The  type  r  of 
each  such  declaration  shall  be  valid. 


T  b  r  rule  T  b  rs  rules  T  b  r  :  type  T,x:t  \-  rs  rules 

- vrs.empty  - vrs_.  - vrs_3 

r  b  empty  rules  T  b  r.rs  rules  T  b  exists  x  :  r.  rs  rules 


This  judgment  depends  on  the  previously  defined  judgments  validating  types  (T  b  r  :  n)  and  rules  (T  b 

r  rule). 

A  valid  role  is  a  valid  rule  sequence  that  is  either  prefixed  by  a  variable  declaration  f orall  x  :  r  for  a 
valid  type  r,  or  paired  with  a  declared  constant  x  using  the  constructor  for  x. 


T  b  r  :  type  r,x  :  r  b  rs  rules  r  b  rs  rules 

- vp_V  - vp_for 

r  b  f orall  x  :  r.  {rs}  role  :  r,  P/;  b  for  a;,  {rs}  role 


21 


r 


CHAPTER  4.  TYPE  CHECKING 


This  judgments  depends  on  the  previously  defined  judgments  validating  types  (T  h  r  :  k)  and  rule  sequences 
(T  h  rs  rules). 


4.4  Errors 

An  implementation  of  type  checking  for  MSR  shall  accept  any  specification  that  can  be  given  a  typing 
derivation  according  to  the  rules  presented  in  this  chapter.  Whenever  an  MSR  specification  cannot  be 
validated  according  to  these  rules,  the  typechecker  shall  report  an  error.  Error  messages  should  be  as  precise 
as  possible  and  contain  enough  information  so  that  the  programmer  can  quickly  fix  their  cause. 
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Execution 


This  chapter  defines  two  variants  of  an  abstract  execution  semantics  for  MSR.  One  is  sequential,  the 
other  parallel.  Both  operate  on  fully  reconstructed  programs  as  described  in  Chapter  [3]  We  also  assume 
that  module  boundaries  have  been  dissolved  so  that  specifications  can  be  seen  as  a  single  body.  Neither 
semantics  requires  programs  to  be  well  typed.  However,  MSR  is  type  safe  under  both,  i.e.,  execution  of  a 
well-typed  program  always  transforms  valid  states  into  valid  states. 

While  we  do  not  discuss  how  to  refine  these  abstract  semantics  into  concrete  MSR  run-time  systems  in 
any  detail,  we  briefly  examine  basic  directives  to  allow  users  to  control  execution. 


5.1  Snapshots 

A  state  of  execution,  or  snapshot ,  is  a  4-tuple  consisting  of  a  multiset  m  of  ground  terms,  a  context  E 
recording  the  symbols  in  use,  an  active  role  set  R  (defined  next),  and  a  multiset  E  of  equations  without  free 
variables.  We  write  this  snapshot  as  [rri]  ^  -  and  abbreviate  it  as  C  when  the  components  are  unimportant. 


g  :=  _ 

An  active  role  set  R  is  a  multiset  of  active  roles,  where  an  active  role  rs A  is  a  rule  sequence  with 
distinguished  owner  A  and  without  free  variables.  Active  roles  are  partially  instantiated  role  suffixes. 


R  ::=  •  |  R,rsA 


The  natural  extension  of  the  substitution  operation  is  defined  over  active  roles. 

Both  snapshots  and  active  roles  are  run-time  artifacts,  unavailable  to  the  programmer. 
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5.2  Execution  Judgments 

The  two  execution  semantics  of  MSR  examined  here  are  specified  on  the  basis  of  the  following  judgments. 
Their  definition  is  given  in  the  next  section. 

t^$>gt'  Equality  modulo  equations 

m!  Left-hand  side  match 

( rhs)s  (Tn)s>  Right-hand  side  instantiation 

r  >  [m]  E  [to']  Rule  application 

B  >  C  — >  C'  One-step  sequential  firing 

B  >  C  — >*  C'  Multi-step  sequential  firing 

B  >  C  =>  C'  One-step  parallel  firing 

B  >  C  =>*  C'  Multi-step  parallel  firing 

5.3  Execution  Rules 

Both  the  sequential  and  the  parallel  execution  semantics  rely  on  the  same  notion  of  state  equality  and  rule 
application. 


5.3.1  Equational  Matching 

Ground  terms  t  and  t'  are  equal  modulo  ground  equations  E  if  rewriting  some  subterms  of  t  using  E  yields 
t'. 


t-i  t\  t2'>p  t'2  t->st’ 

- xeq.id  - xeq.eq  -  xeq_app  - xeq_: 

f>gf  t  t'  ti  t2  t\  tf2  t  :  r  :  r 


States  in  and  m'  are  equal  modulo  ground  equations  E  if  rewriting  some  subterms  of  m  using  E  yields 


m  ^  g  rri  t^>gt' 

- xeq.empty  - xeq_, 

empty  g  empty  m,t.^>g  m! ,  t! 


This  judgment  depends  on  the  equality  modulo  equations  judgment  iti^>g  t!)  just  defined. 


5.3.2  Rule  Application 

A  right-hand  side  is  instantiated  by  replacing  each  existential  quantifier  with  a  new  symbol  and  recording  it 
in  the  context. 


([a /x]r/is)(S,a:r)  >  (to)e' 

- xr  _base  - xr_3 

(m)s  >  (m)s  (3x  :  r.  r/is)E  >  (m)s' 
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To  apply  a  rule,  we  first  instantiate  each  prefixed  universal  quantifier  with  a  term  of  the  appropriate 
type,  obtaining  a  ground  rule  to;  m'r  =>  rhs.  This  rule  is  enabled  in  a  state  to*  if  in*  has  the  form  to,  m,  vn! 
where  m'r  is  equal  to  in'  modulo  the  current  set  of  equations.  This  rule  instance  is  applied  (or  fired)  in  to* 
by  replacing  the  left-hand  side  in'  with  the  result  rri"  of  instantiating  the  right-hand  side  rhs.  This  yields 
the  state  fh,m,m".  Notice  that  the  guard  m  must  be  present,  but  is  not  modified  by  firing  this  rule. 

T  I>  [nr]  s  ^  >  [to/]  p  Rule  application 

E  b  t  :  r  [t/x\r  >  [to]  >  [to']  E<; ^  TO'r  >  -  m>  (r/is)s  >  (to")e' 

-  xr_V  -  xr_=> 

(Vx  :  r.r)>  [to]  E  ^  »  [to']  g  (to;  m'r  =>  rhs )  >  [to,  to,  to']  e  g  »  [to,  to,  to"]  s,  ^ 

This  judgment  depends  on  the  right-hand  side  instantiation  judgment  defined  earlier. 


5.3.3  Sequential  Execution 


Sequential  execution,  or  firing ,  operates  by  copying  a  role  to  the  active  role  set.  Roles  of  the  form  forallx  : 
r.  rs  are  first  instantiated  with  a  valid  owner  of  type  r.  Equations  and  definitions  are  copied  to  the  current 
equation  set  and  instantiated.  Active  roles  are  processed  by  instantiating  existentials  with  appropriate 
constants  which  are  recorded  in  the  context,  by  applying  a  rule,  or  by  skipping  a  rule.  An  empty  rule 
sequence  can  be  disposed  of. 


B>  C 


C 


One- step  sequential  firing 


(5,  for  A.  {rs})  >  [S] "  . 


-  xB_f  or 


[S\ 


R,rsA 

E;i? 


E  h  A  :  r 

R 


xB.V 


{B,  f  orall  x  :  t.  {rs})  >  [S]  £ - 


[S] 


R,([A/x]rs)A 


B,  (x  o:=t)>  [S]«£  — ►  [S]£ 


xE 


- xD 

R 

E;(E,V(o)  x  o  —  t) 

E  b  t  :  T 


B  >  ^  E;(E,forall  x:t.  E) 


[5]  E  ;(E,[t/x]E) 


xE.V 


r  >  [S]  »  [5']  E, 


E';.E 


■n  r  m  R, (exists  x:r.  rs)A 

B>  [s]E;^ 


[s\ 


b>  [5]  -►  [S] 


R,([c/x]rs)A 
(E,c  :t)\E 

xrs.skp 


b>  [s]":E 


R,(r.rs)A 


rcq  fl.(rs)A 


Bt>  [5]Jjmpty)A  — >  [5]« 


■  xrs_empty 


E  :E 


Rule  xD  transforms  a  definition  into  an  equation  by  prefixing  it  with  a  universal  quantifier  for  each 
formal  parameter.  The  notation  V(o)  x  o  :=  t  is  defined  as  follows: 

{V(-)io:=f  =  xo  =  t 

V(x  :  t,o)  D  =  \/x  :  t.  (V(o)  I?) 

This  judgment  depends  on  the  rule  application  judgment  (r  >  [5]  v  [5']  E,)  defined  earlier. 

Multi-step  sequential  firing  is  dehned  as  the  reflexive  and  transitive  closure  of  the  one-step  sequential 
firing  judgment. 
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Bo  C  - 

->*  C 

Multi-step  sequential  firing 

Bo  C  — y  C  Bo  C'  — C" 

- x*_0  -  x*_n 

Bo  C  — C  Bo  C  — C" 


5.3.4  Parallel  Execution 


A  single  step  of  parallel  execution  is  modeled  by  splitting  the  current  snapshot  into  independent  portions, 
doing  one  sequential  firing  step  in  each,  and  reassembling  the  result. 


Bo  C 


C' 


One-step  parallel  firing 


B>  Bt>  Mvk  =►  K] 


'(S.Ei  );b; 


S;B2 


/ 1  R'2 
1 


Bo  C 


C 


p_id 


p_par 


This  judgment  depends  on  the  single-step  sequential  execution  judgment  Bo  C  — C' . 

Multi-step  parallel  execution  is  the  reflexive  and  transitive  closure  of  single-step  parallel  execution 


Bo  C 


C 


Multi-step  parallel  firing 


B>  C 


C 


■  p*_0 


Bo  C 


C'  Bo  C' 


C " 


p*_n 


Bo  C 


C" 


5.4  Properties 

MSR  satisfies  type  preservation  with  respect  to  the  typing  semantics  given  in  Chapter  [4]  and  both  execution 
semantics  just  examined. 

Theorem  1  (Type  preservation) 

Let  decl(H)  be  the  declarations  occurring  in  B.  Given  snapshot  [m]^,  define  B  b  [m]  ^  ^  snapshot 

to  hold  if  b  decl(H),E  context  holds,  decl(i?),E  b  E  eq  holds,  decl(i?),E  b  m  mset  holds,  and 
decl(H),  E  b  R  role  holds. 

If  Bo  and ■  b  B  body  and  B  b  [5]^  -  snapshot,  then  B  b  [5']^,^,  snapshot. 

A  detailed  proof  for  a  variant  of  this  language  can  be  found  in  1 10] .  Type  preservation  for  multi-step  and 
parallel  firing  are  similar. 

Type  preservation  ensures  that,  starting  from  a  well- formed  snapshot,  execution  of  a  well- typed  specifi¬ 
cation  cannot  produce  ill-formed  snapshot.  It  also  implies  that  execution  can  be  implemented  as  not  to  rely 
on  typing  information  except  possibly  for  role  owner  instantiation,  although  this  is  a  useful  debugging  tool. 


5.5  Controlling  Execution 

A  concrete  run-time  environment  for  MSR  shall  be  correct  with  respect  to  the  sequential  or  parallel  semantics 
just  presented.  At  the  minimum,  it  shall  give  the  user  a  command  to  run  a  specification  from  a  specified 
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snapshot.  However,  this  makes  it  hard  to  develop  correct  specifications  and  debug  them  in  practice.  It  is 
recommended  that  the  development  environment  provide  commands  to  inspect  the  state,  limit  execution 
and  control  it.  Some  useful  examples  follow: 

•  init  C:  Set  C  as  the  current  snapshot. 

•  run  [z]  [to]:  Execute  the  specification  from  the  currents  snapshot.  If  the  argument  i  is  present,  do  at 
most  n  steps.  If  the  argument  to  is  present,  stop  when  a  snapshot  matches  the  parametric  multiset  to. 

•  show:  Display  the  current  snapshot. 

•  choices:  Show  the  possibilities  for  the  next  execution  step  from  the  current  snapshot. 

•  choose  n:  Choose  the  n-th  execution  step  possibility  from  the  current  snapshot. 

An  implementation  can  make  more  sophisticated  commands  available  [2Tj . 


5.6  Outputs 

Type  preservation  ensures  that  running  a  well-typed  MSR  program  cannot  result  in  a  run-time  error. 

In  addition  to  the  outputs  of  user  commands  intended  to  control  execution  (see  above),  it  is  useful 
to  provide  facilities  for  tracing  and  debugging  an  execution.  This  includes  step-by-step  snapshots,  partial 
snapshots  that  focus  on  specific  state  elements,  and  execution  statistics. 
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